Applications developed for mobile devices are distributed in a package containing the necessary elements to run the application such as the program code, resources, assets, certificates and manifest. Typically, an application is compiled from the source code and then packaged with the required elements. An application package is then signed and distributed to a device or emulator.
FIG. 1 shows an example packaging flow for an application developed using the Android operating system and distributed in an Android Package File (APK). An Android application, such as the one shown in FIG. 1, is typically written using the Android Software Development Kit (SDK) and in the Java language. During compilation and packaging, the Java code is first compiled into class files in the Java bytecode format. Next the “dx” tool converts the class files containing bytecode into “.dex” files in the Dalvik bytecode, where the Dalvik bytecode is the native format of the Android operating system. If desired, the “.dex” files can be converted into “smali” files using a file format converter called “apktool”.
FIG. 1 shows an example application package (in this case a “.apk” Android Package) comprising the program code in “.dex” files, resources in a resources.arsc file, plus uncompiled resources and a manifest file (AndroidManifest.xml). A command line tool such as Android Debug Bridge (indicated as ADB in FIG. 1) allows the code to communicate with an emulator or an Android device. This may be beneficial during application development as a way to test and debug the application.
Application wrapping is a method of adding a layer to an existing mobile application binary file to add features or modify behavior, without requiring changes to the underlying existing application. For example, native iOS or Android applications can be wrapped to add a management layer to the existing application. In this way, a system administrator can exert control over an application and can set specific rules and policies to be applied to an application or group of applications. Example policies include whether or not user authentication is required for a specific application, whether or not data associated with the application can be stored on the device, and whether or not specific Application Program Interfaces (APIs) such as copy/paste or file sharing are allowed. Other example policies can include when the application can run (such as, for example, day and time of day) and the location from which it can run.
In an enterprise environment, application wrapping increases the level of control and the ease with which control can be applied to specific end users and applications. Application wrapping reduces the risk to the enterprise of unauthorized or improper use of mobile applications. For example, an administrator can take an application, add extra security and management features to it, and then deploy it in the enterprise as a single application package via an enterprise app store.
Typically application wrapping methods are part of the application compilation workflow process. There is a need, however, for technique to wrap pre-built or commercial applications without the involvement of the developer.
Existing technique focuses on application security for non-commercial applications, namely, applications developed in-house. Nonetheless the majority of mobile applications are commercially developed and available via app stores. There is a need for technique to support new license management models where the identity of an enterprise customer can be associated with an application for the purposes of license management, and also application authorization and security policy enforcement.
Existing Mobile Device Management (MDM) technique, for example, relates to securing and managing devices deployed across an enterprise, and does not provide the functional benefits enabled by the present application wrapping technique.
Other existing approaches include (a) the use of virtual machines, (b) a developer writing the added functionality from scratch or using a library, and (c) having the device itself provide the functionality.